fix(engine): correct the inverted depth sign in 3D projection - #3232

Picks up crbug 522872457's fix (CL 8032671), which landed after the
152.0.7935.0 canary cut and so was absent from the old 152.0.7928.2 pin.

Re-probed every 3D signal the compile gate matches, drawElementImage vs a
CDP screenshot of the identical state, on the shipping headless-shell
binary. PSNR, old pin -> new pin:

  backface-visibility:hidden    1.4 dB  ->  14.8 dB   still DAMAGED
  preserve-3d (no backface)    46.7 dB  ->  46.7 dB   clean
  perspective()                45.2 dB  ->  45.2 dB   clean
  matrix3d()                   45.2 dB  ->  45.2 dB   clean
  rotate3d()                   45.3 dB  ->  45.3 dB   clean
  translateZ under perspective 29.9 dB  ->  29.9 dB   marginal

The upstream fix repaired the collateral damage only: dropped sibling
content and lost backgrounds now render, but a culled backface is still
painted. So the 3D gate stays. Beta rather than Canary because
153.0.8000.0 measured identical on every variant.

Follow-up filed as PRINFRA-486: four of the five signals the gate matches
were never broken on any build tested, so it may be able to narrow to
backface-visibility alone. Needs a corpus eval first — this probe covers
static angles only, and animated 3D subtrees take a different path.

… instead of failing (#3172)

* fix(engine): bound drawElement frames so a wedged renderer falls back instead of failing

A single drawElement frame could kill an entire render. On one comp
(caption-editorial-emphasis) drawElementImage returns normally and the renderer
then stops draining its task queue: the setTimeout(…, 0) that schedules
toDataURL never fires, the capture page.evaluate never settles, and 60s later
the stage watchdog fails the whole render. Deterministic on 152.0.7977.30,
always the same frame. Root-cause detail in PRINFRA-488.

Two gaps, both closed here.

1. Nothing below the 60s stage watchdog bounded a frame. Adds a per-frame
   deadline (HF_DE_FRAME_TIMEOUT_MS, default 15000, 0 disables) around the WHOLE
   frame operation, not just the drawElementImage call — the stall surfaces at
   whichever page round-trip comes next, and was observed at both the capture
   and the seek's background-image decode. Bounding one call missed it.

   Deliberately NO per-frame screenshot fallback for this error: once the
   renderer stops scheduling it is wedged for every subsequent round-trip on
   that page. Measured — the screenshot fallback blew the same deadline. The
   frame fails fast instead, so the recovery that actually works can run.

2. That recovery was ineligible. shouldRetryViaPinnedFallback only retried a
   generic capture failure when the worker count was PINNED by the inversion or
   the router; a comp that engaged drawElement on the ordinary single-worker
   path had no whole-render fallback at all. A renderer stall is now retryable
   on any routing — the failure is a property of drawElement itself, and the
   retry re-renders on a fresh page via screenshot. Reported as
   de_fallback_reason "de_renderer_stall" so it is distinguishable from
   capture_error in telemetry, and counted per-session as deFrameTimeouts.

Verified end to end on the repro: previously exit 1 with "stalled: no frame
progress for 60000ms"; now the deadline fires, the render retries via
screenshot, and RENDER_OK with a valid 1920x1080 / 240-frame / 8.0s MP4.

Tests cover the predicate both ways plus the cross-package error match. Engine
1,481 and producer 587 green (audioPadTrim.integration flakes only under
full-suite parallel load — passes in isolation, and on clean HEAD it is green
too, so it is not from this change).

Refs PRINFRA-488

* fix(engine,producer,cli): count drawElement frame timeouts where they happen

`session.deFrameTimeouts` was incremented inside `captureFrameCore`'s catch,
but the deadline races that function from OUTSIDE it — `withFrameDeadline` is
applied by `captureFrameToBuffer`, and `DeFrameTimeoutError` is constructed
nowhere else. So the branch was unreachable: on a wedged renderer the counter
stayed 0, the engine-side stall log never printed, and
`CapturePerfSummary.deFrameTimeouts` reported 0 on every affected render. The
end-to-end recovery worked throughout — `isDeRendererStallError` matches by
name at the producer — only the observability was dead.

Moved the increment and the log into an `onTimeout` hook that fires from the
deadline itself, deleted the unreachable branch and the now-unused
`isDeFrameTimeoutError`, and threaded the count out to
`render_completed.de_frame_timeouts` so the rate is graphable apart from the
other `capture_error` fallbacks. A stall always costs a whole-render re-run,
which is why it deserves its own series.

Also corrected the `fallbackReason` docstring, which still listed only
`psnr | blank | oom | capture_error` after this branch added
`de_renderer_stall`.

`withFrameDeadline` is exported for a two-case fake-timer test: the deadline
fires and calls `onTimeout` once, and a resolving inner promise passes its
value through with no late timer. The first case fails if the counter moves
back inside the work promise.

…streaming

`withFrameDeadline` was applied by `captureFrameToBuffer` alone. The disk path
(`captureFrame`, reachable under the fast-capture opt-in) and the macOS
worker-encode path (`captureFrameToBufferPipelined`) still awaited their
round-trip unbounded, so the same wedged renderer PRINFRA-488 describes failed
the whole render at the 60 s watchdog there — the exact outcome the deadline
exists to replace. The pipelined path does not route through
`captureFrameCore` at all; it calls `produceDrawElementFrame` directly, so its
produce phase is bounded on its own.

All three now share `withDeFrameDeadline`, which also owns the stall counter
and log. The pipelined catch rethrows a blown deadline before the per-frame
diagnostics: those screenshot and evaluate against the page that just stopped
scheduling, so running them would spend the whole budget the deadline saved.

Producer side: the disk-capture catch handled only
`isDrawElementVerificationError` and rethrew everything else, so even a
correctly-raised stall had no whole-render fallback there. It now routes the
stall the same way the streaming drain does, under a new `renderer_stall`
capture-plan failure kind — `sdr_disk` accepts no other kind, and reusing the
verification label would file a fabricated diagnosis in the retry telemetry
(nothing was verified; no score exists).

Wiring is pinned at the source level in the deadline test, since the entry
points need a real Chrome page: each must reference the wrapper, and the
pipelined bail must precede its diagnostics call. Unwiring any one of the three
fails it.